home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c-part2 / 14125 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  4.8 KB
  1. Path: mail2news.demon.co.uk!genesis.demon.co.uk
  2. From: Lawrence Kirby <fred@genesis.demon.co.uk>
  3. Newsgroups: comp.lang.c
  4. Subject: Re: C syntax question
  5. Date: Thu, 11 Apr 96 23:07:56 GMT
  6. Organization: none
  7. Message-ID: <829264076snz@genesis.demon.co.uk>
  8. References: <4ki00k$a4@mailhub.scitec.com.au>
  9. Reply-To: fred@genesis.demon.co.uk
  10. X-NNTP-Posting-Host: genesis.demon.co.uk
  11. X-Newsreader: Demon Internet Simple News v1.27
  12. X-Mail2News-Path: genesis.demon.co.uk
  13.  
  14. In article <4ki00k$a4@mailhub.scitec.com.au>
  15.            johns@rd.scitec.com.au "John Saunders" writes:
  16.  
  17. >I have a question on C syntax that doesn't seem to be covered by the books
  18. >that I have. Maybe somebody with the full ANSI spec. could enlighten me.
  19. >
  20. >Consider the following code fragment:
  21. >
  22. >        typedef unsigned char   byte;
  23. >        typedef int                             data;
  24. >        typedef struct
  25. >        {
  26. >                byte            byte;
  27. >                struct
  28. >                {
  29. >                        int             dummy;
  30. >                }                       data;
  31. >        }       struct_t;
  32. >
  33. >This is supposedly correct C, typedef names are ignored when defining
  34. >structure members. But not when defining variables so:
  35. >        byte    byte;
  36. >is an error when not inside a structure definition. Am I correct so far?
  37.  
  38. Yes, every structure and union type defines a distinct namespace for its
  39. members.
  40.  
  41. >I goal is to write a parser that handles the above correctly, all example
  42. >ANSI C parsers I have seen don't.
  43.  
  44. The C language syntax is defined in terms of a context-free grammar. Therefore
  45. most if not all ANSI C parsers are based on that context-free garmmar.
  46. A context-free grammar is incapable of doing what you want. In addition
  47. to the basic syntax the standard defines a number of 'constraints' such that
  48. if any of them is violated (or a syntax error occurs) then the compiler
  49. must issue a diagnostic.
  50.  
  51. >I started playing around with mixing
  52. >typedefs and type keywords in the same declaration to see how C compilers
  53. >react. This is where it got strange. Consider the code.
  54.  
  55. Mixing a typedef name with any other type specifier violates a constraint
  56. so:
  57.  
  58. >        typedef unsigned char   ubyte;
  59. >        typedef signed char             byte;
  60. >
  61. >        ubyte signed                    i;
  62. >        byte unsigned                   j;
  63. >        signed ubyte                    k;
  64. >        unsigned byte                   l;
  65.  
  66. all 4 of these violate the standard and an ANSI compiler must generate a
  67. diagnostic.
  68.  
  69. >The compilers I tried allowed the declaration of i and j (some gave warnings
  70. >and others didn't).
  71.  
  72. The warnings are fine. The compilers that compiled it silently are not
  73. conforming (at least with the compiler options you used).
  74.  
  75. >However none liked the declaration of k and l.  From this
  76. >it would seem that a typedef name is allowed only as the first token in the
  77. >declaration.
  78.  
  79. Not true. However it must be the only type-specifier. It can be preceded by
  80. a storage-class-specifier (e.g. typedef, static, register etc.) and/or 1 or 2
  81. qualifiers (const, volatile).
  82.  
  83. >All the example ANSI C grammars that I have seen allow any number
  84. >of typedef names or type keywords in any order.
  85.  
  86. The grammars do that because they can't do any better, that is left to the
  87. written constraints. In this case in section 6.5.2:
  88.  
  89. "Each list of type specifiers shall be one of the following sets (delimited
  90.  by commas, when there is more than one set in a line); the type specifiers
  91.  may occur in any order, possibly intermixed with the other declaration
  92.  specifiers.
  93.  
  94.  - void
  95.  
  96.  - char
  97.  
  98.  - signed char
  99.  
  100.  - unsigned char
  101.  
  102.  - short, signed short, short int, or signed short int
  103.  
  104.  - unsigned short, or unsigned short int
  105.  
  106.  - int, signed, signed int, or no type specifiers
  107.  
  108.  - unsigned, or unsigned int
  109.  
  110. ...
  111.  
  112.  - enum-specifier
  113.  
  114.  - typedef-name"
  115.  
  116. So typdef-name is a single set in this context and may not appear with
  117. any of the others in the same type specifier list, including signed and
  118. unsigned.
  119.  
  120. >This is causing a major
  121. >problem in being able to parse "byte byte;" correctly in the structure
  122. >definition. I.e. is the second occurance of "byte" supposed to be treated as
  123. >a typedef name or the member name?
  124.  
  125. As far as the syntax analysis is concerned it is simply an identifier.
  126. After the syntax analysis the compiler can determine that it is a structure
  127. member name from its position in the syntax tree.
  128.  
  129. >Has anyone tackled this problem before?
  130.  
  131. I don't believe there is a problem to tackle (beyond some of your compilers
  132. apparently being non-conforming). You're trying to make syntax analysis do
  133. something it is incapable of. The standard requires many sanity checks beyond
  134. those inherent in the syntax definition.
  135.  
  136. -- 
  137. -----------------------------------------
  138. Lawrence Kirby | fred@genesis.demon.co.uk
  139. Wilts, England | 70734.126@compuserve.com
  140. -----------------------------------------
  141.